Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

2.0.6 is the latest io.keploy:keploy-sdk on Maven Central; older
example pins (2.0.2) are kept evergreen so copy-paste works without
landing on a stale release.

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

The previous Dropwizard dedup contract was 16 tests in a single set
with both EXPECTED_DUPLICATES=any and EXPECTED_RETAINED_TESTS=any —
it only verified "something happened", not that dedup picked the
right tests. Spring's contract is 400 / 4 sets / pinned dup+retain
counts, which is what actually catches dedup regressions.

Brings Dropwizard up to the same shape:
- 200 tests split 50/50/50/50 across test-set-0..test-set-3.
- Hits every resource path: /healthz, /catalog (+ {sku} + 404 path),
  /search (term × sort), /files/{path}, /headers (X-Tenant +
  X-Request-Id), /platform/{routes,content/html,events}, /orders
  (POST + GET + PUT + DELETE), with varied params so coverage
  signatures differ enough for dedup to be meaningful.
- Adds run_random_200.sh — same shape as java-dedup/run_random_1000.sh
  — so future re-records are reproducible.

Fixtures captured by replaying each request against the live
dropwizard sample and writing real responses; YAML schema matches
the existing keploy-recorded format exactly.

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

Previous regen was missing three fields the canonical
keploy-record fixtures carry. Added them so the docker mode
replays cleanly:

- spec.assertions.noise.header.Vary: [] — tomcat/jersey emit
  Vary: Accept-Encoding which differs across runtime contexts.
- spec.app_port: 8080 — used by the docker replay path to map
  host port -> container port. Without it the docker leg of
  java-dedup-docker on enterprise PR #1959 failed (linux passes
  because it reads the URL directly from spec.req.url).
- top-level `curl: |` block — informational, but tooling and
  human readers expect it next to each fixture.

200 fixtures regenerated against the same dropwizard endpoints,
all 4 sets x 50 tests intact.

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

Previous regen wrote a placeholder `# empty mocks` mocks.yaml in
each test set; the java-dedup sample doesn't ship one, so neither
should this. Empty mocks aren't harmful but the asymmetry is noise.

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

The 200 dropwizard fixtures were captured with extra response
headers (Vary, Content-Length) and the 127.0.0.1:8080 host that
Python's http.client emits. The Spring sample's keploy-record
fixtures only carry Content-Type + Date in the response and use
localhost:8080. Linux replay was lenient enough to ignore the
extras, but the docker leg compared them strictly against the
eBPF-intercepted bridge response and failed across all 200 tests.

Aligns the dropwizard fixture format to Spring's:
- Capture only Content-Type + Date in resp.header.
- Drop header.Vary noise entry (no longer needed, header isn't captured).
- Use localhost:8080 in URLs and Host headers (matches Spring).

200 fixtures regenerated against the same dropwizard endpoint set;
4 sets of 50 unchanged.

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

Previous attempt stripped Vary + Content-Length from the captured
response header set to look like Spring's keploy-record output —
that broke linux replay too because keploy strict-compares the set
of response headers, not just values: dropwizard's Jetty actually
emits Vary + Content-Length on the wire, so a fixture that omits
them is "missing" a header from the live response and fails the
match across all 200 tests on both linux and docker.

Restores full header capture (Date, Content-Type, Vary, Content-
Length) and adds `header.Content-Length: []` to noise on top of
Date and Vary. That keeps the header set equal between fixture and
live response while letting docker-mode framing (chunked vs explicit
Content-Length) ignore the value drift that originally broke docker.

Reverts the `127.0.0.1` -> `localhost` host swap from the previous
attempt as well; it was unrelated to the docker failure (keploy
sends the recorded Host header verbatim) and only added churn.

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

Root cause for the docker java-dedup failure (`expected 200 covered
tests, found 134` from common.sh assertion 419-420):

The keploy-v3 sidecar that reads /tmp/coverage_data.sock and writes
dedupData.yaml inside the container has a timer-based flush. Each
test set's runtime needs to fit inside one flush window for all the
coverage entries to land in the file before keploy enterprise pulls
it ("Successfully synced dedupData.yaml from container").

- Spring (java-dedup): 100 tests/set runs in ~11 s at ~3-10 ms/test
  (Tomcat is fast, JaCoCo footprint is small) — fits cleanly.
- Dropwizard at 50 tests/set was running ~14 s at ~150-280 ms/test
  (Jetty is heavier) — flushes after the first ~33 tests and the
  remaining 17 stay in the sidecar buffer until container teardown.

Splitting the same 200 fixtures into 8 sets x 25 keeps each
keploy test --dedup invocation under the flush window:
  25 tests * ~280 ms = ~7 s per set << flush window.

The fixture content is identical to before — just redistributed.
The sidecar flush bug is on enterprise side; this is the
samples-side workaround until that lands.

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

The keploy-v3 sidecar's async write to dedupData.yaml has a
~1.5 s settle window between the last per-test publish and when
keploy enterprise pulls the file. Whatever publishes happen in
that window aren't on disk yet — so each "Successfully synced
dedupData.yaml from container" call drops the trailing ~3 tests.

Going 4x50 -> 8x25 cut the loss from 66 -> 24 (3 per sync x 8 syncs).
Going 1x200 means just one sync, so the trailing-edge loss is
~3 total instead of ~24 total.

Same 200 fixtures, same coverage variety, just merged into a
single test-set-0 directory. Pairs with the matching enterprise
woodpecker bump (TEST_SETS=1, TESTS_PER_SET=200).

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>